feat: add noWait parameter to start_debugging and continue_execution - #116
feat: add noWait parameter to start_debugging and continue_execution#116ankitajha6475-jpg wants to merge 3 commits into
Conversation
|
@microsoft-github-policy-service agree |
There was a problem hiding this comment.
ankitajha6475-jpg Thanks for adding this! Please address the following:
- Remove unrelated generated changes from AGENTS.md, CLAUDE.md and package-lock.json.
- Keep this PR scoped to the noWait parameter: get_debug_state should be proposed separately unless the PR description explains and tests that API addition.
- Add direct tests proving start_debugging({ noWait: true }) returns without waiting for a stop/termination, continue_execution forwards noWait across multi-window routing, and continue_execution({ noWait: true }) does not perform state-change waiting.
- Update the DebuggingHandler architecture documentation to describe the opt-out behavior.
|
Thanks for the review Oz Zafar (@ozzafar)! Regarding When an agent triggers If you agree this belongs in the same workflow, I am happy to update the PR description, documentation, and add test coverage for |
3 participants
Description
Historically, DebugMCP's \start_debugging\ and \continue_execution\ calls blocked synchronously until a breakpoint was hit. If an AI agent invoked \start_debugging\ before informing the user in text, the turn blocked in a tool-call wait state, preventing the user from receiving the prompt instructions.
This PR natively updates \microsoft/DebugMCP\ to support
oWait: true.
The agent can now call \start_debugging(noWait: true)\ to arm the debugger in the background and immediately get control back to output instructions to the user.
The human user can then safely interact with the UI at their own pace. Once the breakpoint is reached, the IDE natively pauses execution and the agent can evaluate expressions.